iT邦幫忙

第 12 屆 iThome 鐵人賽

DAY 2
1
Modern Web

一袋.NET要扛幾樓?打造容器化的ASP.NET Core網站!系列 第 2

[Day 2] 傳統單一架構 VS 微服務架構

  • 分享至 

  • xImage
  •  

本篇同步發文在個人Blog: 一袋.NET要扛幾樓?打造容器化的ASP.NET Core網站!系列文章 - (2) 傳統單一架構 VS 微服務架構

 傳統的單一系統架構,裡面的功能越做越大,導致後續維護越來越吃力。比如今天只要修改購物網站的會員功能,沒有更改其他程式碼,修改完畢後,光是編譯就得花不少時間,後續的測試與部署更不用說,只要中間過程一出錯,從頭來回修改的時間要很久。

 今天微服務架構的特性有兩個:

  1. 小又專精:國軍知名口號「小而精、小而強、小而巧」,用在微服務洽好不過(?),使相關功能的模組都收斂在一個服務,也符合單一職責原則。
  2. 自治性:微服務各自部署在不同機器/平台,彼此開放API並用網路溝通,降低耦合性

 基於這些特性,所帶來的好處有:

  1. 不同技術的Stack:每個微服務可以有自己的技術Stack,比如會員服務可以用ASP.NET Core + SQL Server,訂單服務可以用PHP + MySQL
  2. 高彈性:即使有個服務壞了,其他服務仍可運作
  3. 高擴展性:容易擴充服務,比如負載平衡
  4. 簡化部署:只需針對要部署的服務,其他服務仍保持運作
  5. 減少團隊共同的負擔:以前維護單一系統是所有團隊共同維護,一人更改就得全部受影響;使用微服務可讓團隊專注在自己的服務
  6. 可組合性:微服務可支援多樣的前端應用
  7. 替代性高:如果該服務需要換技術或者移除,比起傳統單一系統容易達成

 但微服務架構也有些缺點,要考慮分散式帶來的問題(比如CAP),還有測試、部署、監控的工作與傳統單一系統不同。

 目前有些台灣公司找後端工程師,不限制使用的技術Stack,很有可能是採用微服務架構,可知這種架構是有幫助的。而我工作環境仍都是單一系統開發,只有Side Project能嘗試這新架構,而且微軟也為相關的文件寫得很充裕,非常的有用!下一篇會開始設計商品列表的Api,敬請期待。

參考資料:

.NET 微服務 - 架構電子書:微服務架構

Building Microservices: Designing Fine-Grained Systems:1. Microservices


上一篇
[Day 1] 系統簡介
下一篇
[Day 3] 建立商品服務的Api - 1
系列文
一袋.NET要扛幾樓?打造容器化的ASP.NET Core網站!30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言